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REMARKS 

This Amendment is submitted in response to the Office Action 
mailed on October 18, 2005. Claims 6, 7 and 13 are pending, and 
all stand rejected at present. Claims 14 - 20 are added. No fee 
is due . 

The word "system" was added to claim 6, to make clear that 
"each" means "each system," and not "each collection." 

Support for the added claims can be found in the Specification 
at the following locations, and others, 



Claim Location of Support 

14, 15, 16 Page 32, line 24 - page 33, line 23 

17 Page 7, lines 12 - 14 

18 Page 27, line 5 et seq. 

19 Page 29, lines 1-6 

2 0 page 26, lines 2 0 - 30 



RESPONSE TO 102 - REJECTIONS 

Claims 6, 7, and 13 were rejected on grounds of anticipation, 
based on the GSPT95 reference. 

Claim 6 
Point 1 

Claim 6 recites, in part: 

6. (Currently amended): An expedited 
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method of assembling software systems, 
comprising the following steps: 

a) fabricating a collection of software systems, each 
of which s ystem contains 

i) a processing module (PROC_MOD) which processes 
content of messages; 

ii) a single packaging module (PAK_MOD) which 
packages said messages into packets for transport 
out of the system; 



The Office Action relies on 

an "authentication module" in GSPT95 to 
show the claimed "processing module" of claim 
6(a) (i) 
and 

a "settlement module" to show the claimed 
"packaging module" of claim 6(a) (ii) . 
However, the claim recites that the "messages" which are 
packaged are the same "messages" which are processed. 

More precisely, the claim recites that the "messages" which 
are packaged by the packaging module are the same "messages" which 
are processed by the processing module. 

That is not present in the reference, for several reasons. 



Reason 1 
The claim states that the 
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packaging module (PAK_MOD) 
packages said messages into packets for 
transport out of the system. 

The reference does not show that "said messages, " which are 
processed by the PROC_MOD in claim 6(a) (i) , are later packaged and 
transported "out of the system." 

Nor has it been shown that the "said messages, " processed by 
the PROC_MOD of claim 6(a) (i) , are packaged by the PAK_MOD as in 
claim 6(a) (ii) , and transported. 

To show these recitations, at a minimum, 

the authentication module in the reference 
must process messages, as claimed, 
and 

the settlement module must package "said 
messages," and transport them, as claimed. 
Neither has been shown. 

Reason 2 

This reason will rebut a possible interpretation of the 
reference . 

The reference states that some element is passed by the 
authentication process to "the external financial institution." 
(Page 4, last paragraph - page 5, first paragraph.) Is that 
element the claimed "message" ? No, as will now be shown. 
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The claimed "message" is processed by the PROC_MOD, which the 
Office Action asserts is shown by the reference's authentication 
module. The authentication module processes the data discussed in 
item 5 on page 4 of the reference. 

However, that data is not passed to the external financial 
institution. One reason is that the purpose of the authentication 
module is to send a "Yes 11 or "No" to the external financial 
institution (to authorize a transaction) . The purpose is not to 
relay all information it receives to the financial institution. 

Thus, the data in question in the reference is not passed to 
the financial institution. The data in question cannot correspond 
to the claimed "message." 

Further, under the claim, the "message" must be packaged by 
a PAK_MOD, and then transported. That has not been shown. It has 
not been shown that the reference's settlement module (which is 
used to show the PAK_MOD) packages and transports "said messages" 
as claimed. 

Stated more simply, in the reference, the data processed by 
the authentication module is not packaged and sent out of the 
system by the settlement module. Something else is sent out, to 
the financial institution. That something else does not correspond 
to the claimed message. 
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Reason 3 

Under the PTO's interpretation of claim 6(a) (i) and (ii) , the 
settlement module of the reference receives the "message" processed 
by the authentication module. 

Applicant respectfully submits that this interpretation is not 
correct . 

The reference states that the authentication module performs 
"authorization" and "authentication." Those steps process data 
described in the reference. (Page 4, items 5 through 7.) But that 
data is not sent to the settlement module. 

Instead, the settlement module receives a "transaction, " and 
enters it into a "log." (Page 5, item 7, last paragraph.) 

There is no reason to store the data processed during 
"authorization" and "authentication" in any settlement log. Nor 
does the reference describe such storage. 

Therefore, no "message" as in claim 6(a) (ii) is found in the 
reference. 

If such a message were present, it would be the "message" of 
claim 6(a) (i) . That would require that the data processed by the 
authentication module, as in items 5 - 7 on page 4, be transmitted 
to the settlement module. No such transmission has been described. 

Nor has storage of that data in the settlement module been 
described. 
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Interim Conclusion 
Claims 6(a) (i) and (ii) are not found in the reference. 

Point 2 

The Office Action asserts that the "settlement modules" of the 
reference show the PAK_MOD of claim 6. 

Applicant points to Figure 2 of the reference. That Figure 
shows multiple settlement modules in a single payment switch. 

Claim 6(a) states that "each" "software system" "contains" a 
"single" PAK_MOD. The reference does not show that. Figure 2 
shows multiple settlement modules. 

The claimed single PAK_M0D is not found in the reference. And 
the reference shows the contrary: multiple such modules. 

Point 3 

Applicant submits that no "system control module" as in claim 
6(a) (iv) has been shown in the reference. 

The Office Action, page 4, states that this "module" is found 
in the "payment system software" of the reference. However, that 
does not identify a "module" which is distinct from the other 
modules supposedly found in the reference. 

For example, Applicant asks: "What does the ' payment system 
software' do which is not done by the authentication, settlement, 
and authorization processes of the reference ? And where is this 

12- 



09/550,192 
Art Unit 3624 
8446.00 

described ?" 

Thus, no separate "system control module, " as claimed, has 
been identified. 

Further, the claim states that the "system control module" 
"coordinates" the processes of claim 6(a)(1), (ii) , and (iii) . 
Applicant cannot locate such "coordination" in the reference and 
requests, under 37 CFR §§ 1.104(c)(2) and 35 U.S.C. § 132, that 
the "coordination" be identified. 

MPEP § 2131 states: 

A claim is anticipated only if each and every 
element as set forth in the claim is found, 
either expressly or inherently described, in 
a single prior art reference. 

Point 4 

Claim 6(b) (iii) (A) states that every PAK_MOD module contains 
a "software unit A." 

The Office Action, page 4, asserts that this "software unit 
A" is found in a certain type of functionality which is present in 
the settlement modules of the reference, which are used to show the 
PAK-MOD modules. 

However, this amounts to double -counting of the settlement 
modules, to show both 

(1) the PAK-MOD modules of claim 6(a) and 

13 



09/550,192 
Art Unit 3624 
8446.00 

(2) the "software unit A" of claim 6(b) . 
Double-counting is not allowed. The MPEP section, cited 
immediately above, requires that every claim recitation be shown 
in the references. 

From another point of view, in the reference, if the "software 
unit A" provides the functionality asserted (ie, providing the 
"common interface"), then the settlement modules alone (without 
software module A) lack that functionality. That is, the 
settlement modules without software unit A cannot act as the common 
interface . 

Consequently, the settlement modules alone do not qualify as 
the PAK_MODs of claim 6(a) (ii): they lack the common interface. 
They cannot perform the function recited in claim 6(a) (ii) . 

The Office Action admits this. On page 5, top, it states: 
" [Without software module A] the modules would not be capable of 
providing the adapted functionality." 

Therefore, the Office Action states that the settlement 
modules require software unit A in order to function as claimed. 
Thus, settlement -module -plus -A must be used to show the PAK_MOD of 
claim 6(a) (ii) . Nothing is left to show the "software unit A" for 
claim 6(b) (iii) (A) . 

Point 5 

Contrary to Point 4, above, claim 6(b) (iii) could be 
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interpreted as merely setting forth the contents of the PAK_MODs, 
which contents perform the packaging recited in claim 6(a) (ii). 
Under this interpretation, the claim passage may be found in the 
reference . 

However, Applicant submits that the structure of the claim 
does not allow this interpretation. For example, if software unit 
B is required for the packaging, then the PAK_MODs lacking software 
unit B could not perform packaging. 

Therefore, Applicant submits that the only reasonable 
interpretation of the claim is that the PAK_MOD of claim 6(a) (ii) 
performs packaging, as claimed, and that the software units A, B, 
and C perform other tasks, but are contained within the PAK_MOD 
modules . 

The reference does not show this. 

Point 6 

Claim 6(iii) states that 

some PAK_MODs contain B but no C, 

and 

some PAK_MODs contain C but no B. 
The Office Action asserts that the reference shows this 
because the settlement modules interface with different networks. 
The Office Action asserts that one settlement module would be 
equipped with only B for one network, and another with only C for 
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another network. 

However, this difference has not actually been shown in the 
reference. The difference must be shown. 

Further, the same result (ability to interface with different 
networks) can be attained if all settlement modules contain both 
B and C. Thus, if the reference states that a module must 
interface with different networks, it may accomplish that by 
inclusion of B and C with all modules. That is contrary to the 
claim. 

In fact, this latter interpretation is consistent with Figure 
2 of the reference. That Figure shows multiple authentication- and 
settlement modules in a single payment switch. 

Why are multiple settlement modules present, if all are 
identical ? They must be of different types, such as B and C. But 
they are in the same switch, contrary to the claim. 

This latter conclusion is further supported by the reference, 
page 5, last paragraph, which states: 

We have created a modular library of 
authentication techniques, and have written 
settlement modules for multiple financial 
networks in response to merchant requirements. 

The Abstract, and other locations, of the reference indicate 
that the Internet is being used as a communication network. 

Therefore, it is clear that the "multiple financial networks" 
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identified on page 5, last paragraph, are reached through the 
Internet. Thus, a given payment switch must be able to handle 
those multiple financial networks. Consequently, that payment 
switch would not be configured for a single network, but for 
multiple networks. Both B and C would be present, contrary to the 
claim. 

Point 7 

Claim 6(b) states that (1) identical CONTROL modules, and (2) 
identical COM_MOD modules are contained in all of the systems. 

The Office Action, in purporting to find PAK_MODs having (1) 
B without C and (2) C without B for claim 6(b) (iii) , asserts that 
different systems will communicate with different networks. Thus, 
the Office Action concludes, the PAK_MODs will be different: some 
will contain only B, others will contain only C. 

However, the claim states that the CONTROL module 
"coordinates" the PAK_MODs (and other modules) . If the PAK_MODs 
are different, as the PTO asserts, then the CONTROL modules must 
also be different. 

Consequently, if the PTO's assertion is correct as to claim 
6(b) (iii) (B) and (C) (asserting that the PAK_MODs are different), 
then claim 6(b) (i) cannot be found in the reference. The reason 
is that the CONTROL modules must then be different, to "coordinate" 
the different PAK_MODs . 
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A similar comment applies to claim 6 (b) (ii) . The COM_MOD 
modules must be different. 

Conclusion 

Applicant submits that the reference does not show claim 6. 

CLAIM 7 

The discussion above applies to claim 7. 
In addition, claim 7 states: 

7. (Currently amended) : Method according to claim 
6, wherein step b) includes: 

iv) fabricating PR0C_M0D modules in all of the software 
systems, such that each system contains a single PROC_MOD 
module, and : 

A) copies of a software unit D is contained in 
every PROCJVIOD module; 

B) some PROC_M0D modules contain a software unit 
E with no unit F; and 

C) come some PROC_MOD modules contain a software 
unit F with no unit E. 

In brief: Applicant points out that Figure 2 of the reference 
is directly contrary to claim 7. 

The Office Action asserts that the "authentication module" of 
the reference show the claimed PR0C_M0D module. 

The Office Action asserts that, if 

authentication module no. 1 performs a 
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certain set of functions, and 

authentication module no. 2 performs a 
different set of functions, 

then 

module no. 1 can be said to contain unit 
E without F, and 

module no . 2 can be said to contain F 
without E. 

Figure 2 of the reference, and its discussion in the text, 
show multiple authentication modules. Multiple modules are present 
because they perform different functions. 

Therefore, the claimed single PROC_MOD is not present. 

Figure 2 of the reference is contrary to the claim. 

CLAIM 13 

Claim 13 is considered patentable, based on its parents. 

ADDED CLAIMS 

New claim 14 states that a software unit can be added to a 
different PAK_MOD. The reference does not show that. And the 
PTO's interpretation of the reference is contrary. The PTO 
interprets the software unit as being found in a function of a 
piece of software. But a function does not imply a unit which can 
be added to another module. 
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New claim 15 states that a software unit can be added to a 
different PAK_MOD, and the unit has separate existence. The 
reference does not show that. The comment to claim 14 applies 
here . 

New claim 16 states that A, B, and C are not needed for the 
packaging. If not, then claim 16(b) (iii) is not reciting 
properties of the PAK_MOD which performs the packaging, but is 
setting forth units (A, B, C) which are added to the packaging 
module . No additions to a packaging module are found in the 
reference . 

New claim 17 states that the "message" of claim 6 contains 
data relating to bank checks. The reference does not show that. 

New claim 18 states that the "message" of claim 6 contains 
data relating to bank checks, and a digital signature. The 
reference does not show that. 

New claim 19 states that the data of claim 18 includes a 
number indicating a bank for each check, and a step of verifying 
correctness of the number. The reference does not show that. 

New claim 20 recites steps undertaken with respect to the data 
indicating bank checks. The reference does not show these steps. 

Response to 112 - Objections 

Point 1 

In response to the phrase "and these host systems range from 
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proprietary systems to UNIX and Windows NT systems, " contained in 
the third paragraph of the DETAILED DESCRIPTION OF THE INVENTION 
(the paragraph beginning with "Thirdly . . . " ) , Applicant points 
out that UNIX is already capitalized. 

Further, the undersigned attorney believes that a Federal 
District Court has held the term "Windows 11 to be generic, and thus 
not subject to trademark protection. 

Nevertheless, in the interest of furtherance of prosecution 
of this application, "Windows" has been re-written in upper-case 
letters. This is not an admission that the term is a valid 
trademark, because the undersigned attorney simply does not know. 

Point 2 

Objection was made to a passage on page 4, lines 3 - 4, of the 
Specification, on the grounds that the passage suggests that "UNIX 
and WINDOWS NT are not proprietary trademarks associated with 
proprietary operating systems." 

Applicant points out that the language of the Specification 
states several the following. 

That electronic payment systems can be 
proprietary (as when a small company designs, 
builds, and operates the system) . 

That electronic payment systems can be 
built around the UNIX or Windows operating 
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system. 



The latter statement in no way suggests that UNIX or Windows 
is non-proprietary. The overall statement merely contrasts (1) a 
payment system built around a UNIX or Windows operating system, 
with (2) an entirely proprietary system (which may have no 
operating system.) 

Nevertheless, in the interest of furthering prosecution, the 
passage has been re-written. 

CONCLUSION 

Applicant expresses thanks to the Examiner for the careful 
consideration of this application. 

Applicant requests that the rejections be withdrawn, and all 
claims be passed to issue. 



NCR Corporation 

1700 South Patterson Blvd. 

WHQ - 4 

Dayton, OH 45479 
February 1, 2006 
(937) 445 - 4956 



Respectfully submitted, 
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